Most commercial aircraft today are equipped with an IFE system. Typically, an IFE system includes a plurality of computers, which are connected to provide various functions. These computers include, for example, audio/video head-end equipment, area distribution boxes, passenger service systems (PSS), and seat electronic boxes. In the modular environment of an aircraft, each of these computers is referred to as a line replaceable unit (“LRU”) since most are “line fit” on an assembly line when an aircraft is built and tested. At least some of the LRUs are connected directly to passenger seats, either individually or by seat groups. These LRUs are the interface between passengers on an aircraft and the IFE system, and provide access to a plurality of functions. A more sophisticated, multi-functional IFE system may include close to a thousand separate connected computers working together to perform the plurality of functions of the IFE system.
The LRUs within a conventional IFE system typically include relatively simple electronics and microprocessors for performing system functions. The channel and volume of the audio provided to a seat are conventionally controlled by a seat electronics box serving a group of seats, the seat electronics box including a microprocessor and signal conditioning electronics to handle audio/video input signal. In some known systems, the seat electronics box can be overridden by the cabin announcement system to allow for flight crew to interrupt audio or video with safety announcements for the passengers. IFE systems must meet strict requirements set by the Federal Aviation Administration (FAA) for avoiding interference with safety critical flight electronics in the cockpit and elsewhere on board. In addition, the aircraft industry has set strict requirements on IFE systems, for example, on the power use, bandwidth, and weight of an IFE system. An IFE system provider is severely restricted in choosing particular hardware and software components for these reasons.
Methods and systems for controlling an IFE system have typically been implemented with software instructions executed in a “master-slave” architecture. Specific functions for the master-slave system have been implemented with proprietary, application specific, and custom software. Electronics used for more complex functions of the IFE system have typically included computers with microprocessors and memory. Custom software has been required for each master and slave computer, and for each function to be performed. Each piece of custom software must be integrated and tested within the system separately. For even the simplest function to be performed, integration and testing is labor intensive and error-prone.
Custom software has conventionally been used, for example, to implement a cabin management terminal, which interacts with other hardware such as tape players, digital media players, or game consoles. Each of the interfaces between the management terminal and the other devices within the IFE system has been programmed and tested separately. For each piece of hardware implemented within the IFE system, one interface (for example, the interface between a master computer and a particular type of slave computer) must be defined, and two software programs must be developed and tested (one for the master and one for the slave). If additions or changes to the system are later desired, such changes are time consuming and require a high degree of familiarity with the details of the original system design.
Attempts have been made to speed up design, testing, and maintenance of a conventional IFE system by combining software components that otherwise would have been separate, or by using software components designed for one device with a different device. Unfortunately, such efforts have resulted in a larger number of system errors and software bugs, and those software bugs have been more difficult to fix since the effects of changes to the software are more difficult to predict when the software runs on multiple types of hardware within the system.
Furthermore, due to the custom nature of the software in conventional IFE systems, as newer models of a system are developed, it becomes difficult for a system provider to support its legacy models. Engineers who designed older models may have left the system provider, and new engineers may not have the time or ability to learn how the older system was implemented. Diagnosing and fixing bugs in a system with a proprietary hardware and software architecture requires time and effort simply to learn how the system works. Maintenance resources are often wasted teaching new engineers how a highly proprietary system works.
A need, therefore, exists for an IFE system that has an architecture that is simple to implement, modify, diagnose, more modular, and easier to interconnect.